Computer systems have evolved over the recent past with technical improvements that have resulted in many new devices or peripherals such as CD-ROMs, portable printers, speakers, color high definition displays and audio sound cards and video adapters becoming widely available. With these devices, together with the enhanced microprocessor at the heart of the computer system, power consumption, or more particularly, power management, has become an issue. Thus it has become common practice to utilize one of several available power management schemes to manage power consumption of the computer system.
Power management schemes have been widely adopted to permit unused devices to be placed into a sleep state even when the computer system is active with one or more tasks. For example, if the computer system is engaged in a word processing application program, the screen and processor will most likely be in active use. However, since the disk drive, CD-ROM, printers and many of the other devices will rarely be activated by the application program, these devices may be placed the sleep state to conserve power. When the application program requires, by way of example, a write or read to disk, the disk drive is awakened and returned to its full operational, and high power, state for the data transfer operation.
In one existing power management scheme, power management has been performed primarily at the device level. With this scheme, power management is independent of the operating system so devices are compatible with a variety of computer systems. Under this scheme, the power state of each device is set by its device driver based on pre-configured profiles determined by the user or by system default states stored in the system Basic Input/Output System (BIOS) memory. When a power state of a device is to be changed, the device driver generates a system interrupt which halts operation of the processor's current task so that new power state data may transferred to the device driver. The change in power state occurs independently of current operating system activity.
System level interrupts, however, suffer from numerous disadvantages. Specifically, system interrupts may cause loss of incoming data during the period when the processor is responding to the interrupt. Loss of data may be merely annoying or may create significant errors if the computer system is unable to process data. By way of example, a universal serial bus (USB) allows the keyboard, modem, CRT display device, mouse and other devices to communicate through a multiplexed serial link that transmits information in one millisecond frames. Since the information is parsed, data may be lost during the time the central processor is responding to a system interrupt because the USB is highly time dependent and cannot tolerate the unknown and unanticipated delay caused by system interrupts.
Further, as operating systems and application programs become more powerful and sophisticated, the decentralized nature of operating system transparent power management makes it difficult to anticipate when the interrupts will occur. Thus, unscheduled interrupts may degrade performance of some application programs.
Further still, decentralized power management complicates the gathering of information relating real-time operational parameters of the computer system so that context-sensitive operating frequency and power levels are selected. For example, if the ambient temperature is high, power may be conserved by reducing the operating frequency and/or the voltage applied to the central processor or other devices if high speed is not necessary.
More recently, certain computer manufacturers and an operating system developer have proposed a specification for evolving power management functions to operating system control. The specification, known as the Advanced Configuration and Power Interface ("ACPI") specifies the interface requirements between devices and the operating system. This interface sets forth the technical standards and requirements so that the operating system controls power management and device configuration as described in the publication: Advanced Configuration and Power Interface ("ACPI"), draft revision 0.99, dated Dec. 16, 1996 and available from Intel Corporation, Toshiba Corp. or Microsoft Corporation, which publication is incorporated herein by reference.
Referring now to Prior Art FIG. 1, an architectural diagram describing the relationship of the software and hardware components of the ACPI interface is shown. The ACPI interface includes five basic components: the operating system kernel 112 (which includes operating system power management software code 114), ACPI dual-ported registers 116, ACPI BIOS 118, ACPI tables 120, and an ACPI driver 122. ACPI driver 122 provides the interface between ACPI registers 116, ACPI BIOS 118, ACPI tables 120, and OSPM system code 114. ACPI registers 116, ACPI BIOS 118, and ACPI tables 120, are coupled to platform hardware 124 which includes, by way of example, a microprocessor, memory, and a plurality of peripherals, or devices, such as disk drives, displays, a keyboard, a mouse etc. As is well understood in the art, operating system kernel 112 interfaces with platform hardware 124 by way of one or more device drivers 126, once platform hardware 124 has been initialized. Initialization data for each device is stored in system BIOS 128 and is automatically transferred to platform hardware 124 and device drivers 126 when power is initially applied to the computer system.
Under the ACPI scheme, power management functions will be controlled by OSPM system code 114. OSPM system code 114 issues commands through ACPI driver 122 and receives information regarding platform hardware operational and power states in return. ACPI tables 120 contain necessary information that permits the operating system to recover details on the configuration of the platform upon power-up initialization. Accordingly, upon initial power-up, ACPI BIOS 118 supplies information from ACPI tables 120 to ACPI driver 122. Based on information held in ACPI registers 116 and the information available to OSPM system code 114, real-time power management of the hardware platform is controlled by operating system kernel 112. In this manner, unanticipated system interrupts of unknown duration are avoided or executed in a controlled manner.
The contemplated architecture, however, suffers from numerous disadvantages. For example, the architecture is not yet completely defined and future changes may negatively impact proper interface of devices designed to function in accordance with preliminary drafts of the specification. Also, since specifications are rarely static, future changes in the specifications will likely require the owner of the computer system to upgrade existing hardware to match or take advantage of any new features that may be later implemented. Still further, legacy devices that currently handle power management functions at the device level are unable to be efficiently interfaced with the ACPI-based operating system kernel 112.
Further, there is only limited provision set forth in the specification by which hardware manufacturers can implement custom power management functions or add features to devices or the microprocessor itself since the ACPI BIOS and ACPI driver control must conform to the published standards. Specifically, the ACPI interface incorporates pseudo-code (often referred to as "P-code") to implement predefined control methods. Since interpretation of P-code is slow and requires the involvement of the central processing unit, it is desirable to provide a mechanism that is independent from the operating system by which innovative power management functions may be added while remaining fully compliant with the ACPI interface standards.
Accordingly, it is desirable to provide a migration path for legacy devices (which utilize system interrupts) to comply with the ACPI interface standards and to add novel power management functions while remaining fully compliant with the ACPI interface standards.